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Please substitute the following paragraph for the paragraph on page 4 starting at 
line 14: 

These patents are not directly applicable to EDI, and therefore do not 
provide or teach that there is an intelligent editor within the customer order 
fulfillment system, or that post-processing modifications can be made to a 
customer order through the order fulfillment system. It is therefore an object of 
the present invention to provide an integrated system and method for pre- 
processing electronic data requests before they are sent to an order processing 
system that provides a planning and forecasting engine that determines if material is 
available for a given quantity and delivery date. These systems also do not enable 
corrections to be made to electronic data requests before they are sent to an order 
processing system. Nor do these systems allow electronic data requests to be 
rejected so that they are not sent to an order processing system when certain 
criteria specified within the electronic data request cannot be satisfied. 



Please substitute the following paragraph for the paragraph on page 5 starting at 

line 2: 

It is therefore an object of the present invention to provide an integrated 
system and method for pre-processing electronic data requests before they are sent 
to an order processing system. 



Please substitute the following paragraph for the paragraph on page 14 starting at 
line 8: 

Figure 4 shows a functional flow diagram of the pseudo-sales order 
workbench 206. When ESO errors are encountered, workflow items are 
created by the SAP Workflow, as indicated in function block 402. The 
workflow items are sent to the in-basket of the responsible person. When the 
work item is executed, as shown in function block 401, the work flow is 
displayed on a user terminal, as indicated by step 407. ESOs can also be 
displayed from the SAP workflow 402 that satisfy selection criteria that a user 
inputs into display block 403. Work flow messages are created under pre- 
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defined conditions and routed to the responsible person for action. Responsible 
persons can view and execute their messages from their SAP Office Inbox (not 
shown). When the message is executed, the user is branched to the appropriate 
application to correct the condition. In a preferred embodiment of the present 
invention, a workflow message is created when the order interceptor 201 
encounters an error or determines that a manual review of the ESO is required. 
The user can also input selection criteria via the input screen, as shown in step 403, 
to display ESOs that satisfy the selection criteria, as shown in function block 401 . 
The ESOs are stored in accordance with the SAP AG Corp. ESO tables ESO 
Control 404, ESO Data 405, and ESO Status 406. These tables validate the ESO 
structure, and pass control to ALE where the ESO can be processed into the 
appropriate business object, such as a sales order or a purchase order 
acknowledgment, etc. The error message table 415 displays the error messages, as 
shown in function block 408. Once the error messages have been displayed, the 
user can also view the fields 409 associated with the ESOs on the pseudo-sales 
order workbench 206, as shown in function block 409. The user can also perform 
various operations on the ESO, as indicated in function block 410. A test is then 
made in decision block 41 1 to determine if the ESO complies with the 
configuration rules and updates. If the ESO does not satisfy the configuration 
rules, a message is sent to the Pseudo-sales Order Workbench, as shown in 
function block 412. If the ESO satisfies all configuration rules and updates, then 
the ESO is updated in tables 404, 405, 406 and 415. The process returns, as shown 
in function block 414. If the user specified selection criteria is via display 403, then 
the return is to the user's display terminal 403. If the SAP workflow 402 created 
the work item, then the return is back to SAP workflow 402. 



Please substitute the following paragraph for the paragraph on page 21 starting at 
line 16: 

If pre-processor module 603 detects an error or manual review condition, the 
workflow module 605 creates a workflow that is made available to the in-basket of 
the responsible person. Once the work item is executed, the customer purchase 
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order workbench module 607 provides a display to a user terminal. The user 
interface is modeled after the incompletion log for processing sales orders. The 
initial screen will display a list of messages identifying why the request was held 
along with key information from the ESO's control and data record segments. If 
the user is authorized, each item in the list can be executed and taken to the 
appropriate screen to correct or review the data. After each correction, the ESO is 
reprocessed by pre-processor module 603. After executing the message, control 
goes back to the main screen. Messages will be removed from the list if it now 
passes all the edits and audits for that rule. If the request was held for manual 
review, the User can navigate to an overview screen to review the request using 
screens similar to those in SAP sales order process. There, certain fields can be 
updated, such as sales area and delivery plant. Some fields however, can only be 
changed in conjunction with executing specific messages. For example, the 
customer's PO number can be changed only if a duplicate error is detected. For 860 
change order requests, the corresponding sales order information can be displayed 
to assist the user in analysis by drilling down on the order number field. 
Additionally, a branch to the native SAP IDOC Workbench can be made by drilling 
down on the ESO number, as provided by the analyzer drill down report module 
611. Access is now available to all ESO segments and data that may not have been 
available in customer purchase order workbench module 607. 



Please substitute the following paragraph for the paragraph on page 25 starting at 
line 15: 

If the Z JDCO JNPUT_PRE ^PROCESS module 603 determines that a previous 
^ request for a customer and given purchase order is pending an acknowledgment, 

(o then the inbound ESO's status will be set to 'Queued for Pre-Processor 5 (Z0). The 
definition of incomplete in this case means that a prior ESO has not been posted by 
the sales order application or the original sales order is incomplete or blocked for 
any reason. This feature can be disabled by changing the corresponding column in 
table 508 using trx ZEDI. The ZMOM101 module 614 will be scheduled as a 
reoccurring job run hourly to process ESOs in this status. Each request will be 
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q checked for pending acknowledgments. If the request is cleared for process, then 
fa control is passed to the Z_IDOC-INPUT module 610 which calls the pre-processor 
and manages the ESO's status and work item; otherwise, the request is held until 
the next run of the ZMOM101 module 614. 



Please substitute the following paragraph for the paragraph on page 28 starting at 
line 1 : 



Q 



The SAP Supplied Function Modules with User Exits module 616 
functions with SAP function modules IDOC_INPUT_ORDERS 616 to post new 
sales orders, ICOC_INPUT_ORDCHG 616 to change existing sales orders, and 
IDOC_INPUT_DELINS 616 to add FDS and JIT scheduling releases. User exits 
are available at key points in the process to allow local modifications as necessary. 
Module 616 enables additional data, such as delivery plant, delivery block, fixed 
quantity ind., additional partners, and pricing reference material to be loaded into 
the BDC session. For delivery schedules, IDOC_INPUT_DELINS (not shown) 
supports customer expected pricing condition EDI1 with screen logic. No edits 
and audits are performed in these exits. These types of functions are performed by 
pre-processor module 603 and worked in workbench module 606 before this stage. 



Please substitute the following paragraph for the paragraph on page 40 starting at 
line 6: 



For new sales order requests, the order type is determined based upon the 
ESO's logical message type (edidc-mestyp) and message code (edidc-mescod). If 
the message type is ORDERS and message code not equal to BPO (for blanket 
PO), then the order type is defaulted to 'OR' for standard order. If the message 
type is ORDERS and message code is BPO, then order type is defaulted to 'ZBO' 
for contract. After the internal material is determined, the default order type can 
be overridden from the local EDI Configuration table/field ZEDITCFG- 
ZOVRAUART (rule is only applicable at material level). 
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Please substitute the following paragraph for the paragraph on page 41 starting at 
line 6: 

For new sales order requests, the Sales area is determined from table 
EDSDC. The keys to this table are KUNNR (Customer number) and LIFNR 
(V endor number sent with EDI). The Customer number is the Sold-to number and 
the Vendor number represents our Sold-to number at the Vendor. LIFNR is taken 
from the LF partner (E 1 EDKAI-P ARTN) field on the ESO. If this field is not 
provided, the LIFNR is taken from the AG partner (E 1 EDKAI-LIFNR) field on 
the ESO. Together, these fields determine the Sales Area. For changes to an 
existing sales document, the Sales area is taken from the existing document. 



Please substitute the following paragraph for the paragraph on page 43 starting at 

line 1: . 

For a new sale order request, or change to an existing order (line item add 
or change where the Customer's material number does not match the Customer's 
material number on the corresponding line item (using Customer's line number)), 
the delivering plant is determined from the material's sales view (table MVECE, 
field DWERK). For change to an existing sales document where the Customer's 
material number does not change, the internal material is taken from the matching 
line item in the order. 





Please substitute the following paragraph for the paragraph on page 56 starting at 
line 23: 

Verify that an FDS (Forecast Delivery Schedule) exists in table VDLB 

where ABART = and ABRLI - 0 



Please substitute the following paragraph for the paragraph on page 56 starting at 
line 25: 

If mode is append (E 1 EDP 1 0-LABKY = 6 T), then any open delivery 
/ 0 schedules are brought forward and appended as delivery schedules on the 

ESO (segment El EDP 16). This audit is performed only once. Open 
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schedules are determined by comparing tables VBEP and VBBE. If the 
J schedule is still open (entry is VBBE), then the delivery schedule is brought 

forward. In addition, any shipments against the delivery schedule are also 
applied to the ESO (E 1 EDP 1 6-FZABR) and are subsequently available for 
display in the Workbench. The delta between the request quantity and ship 
quantity is sent to PROFIT/ATP for commit. The shipped quantity for a 
delivery schedule is derived from VBEP-WMENG minus VBBE-OMENG. 



Please substitute the following table for the table on page 57: 





Segment-Field 


Description 


Rule 




E 1 EDK 1 0- ABRAB 


Release valid-from date 


Earliest request date 






(E1EDP 1 6-ED ATUB) 
on ESO including those 
brought forward for 
JIT 




E 1 EDK 1 0- ABRBI 


Release valid-to date 


Latest request date 
(E 1 EDP 1 6-ED ATUB) 
on ESO including those 
brought forward for 
JIT 




E 1 EDK 1 0- ABHOR 


JIT valid-to date 


If JIT release, then set 
to El EDK 10- ABRBI 



Earliest request date (E 1 EDP 1 6-ED ATUB) on ESO including those 
brought forward for JIT. 



Please substitute the following paragraph for the paragraph on page 60 starting at 
line 26: 



If the Input Mode is not from the Pseudo-Sales Order Workbench (implies 
Work Item already exists), a Pseudo-Sales Order Workbench Work Item is created 
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using function module c Z_Workflow_Error_Create\ The Work Item text consists 
\ of order type and action, delivering plant, internal material, Pseudo-Sales Order 



and Customer name. 



Please substitute the following paragraph for the paragraph on page 63 starting at 

line 15: 

• Line items canceled by Customer are denoted with 4 D" in field XVBEP- 
' ^ UPDKZ 



4 



Please substitute the following paragraph for the paragraph on page 64 starting at 
line 1 : 

The request is then sent to Pre-ATP (function module Z_IDOC_INPUT- 
PRE-ATP (313)) which populates the ATP / SAP Interface table ZATPDEM with 
the information supplied in the API (see structures and tables above) and interfaces 
to ATP as instructed in the API via MQSeries. Parameter TRIGGERATP ('x' 
send to ATP) controls if the request is to be sent to ATP. This is the case for all 
ESOs except when commits are present on the ESO (from OEMLS (1 1 1), for 
example). Parameter RESENDCOMMIT is only used when an ESO is rejected 
by Customer and the request has been committed by ATP and the logical message 
is ORDCHG or DELINS. When RESEND COMMIT = 'x\ then the commits on 
the existing order are resent to ATP to replace the latest commits vs 
RESEND COMMIT = 6 ' which means requesting a commit. Parameter 
TRIGGERZMOM 1 03 tells ATP to raise an event to trigger the Restart ESOs in 
Z4 Status (ZMOMI03) module (319) upon returning the ATP results. If the link 
to ATP is not responding in a timely manner (currently set to 60 seconds), the Pre- 
ATP function is re-executed with the trigger set to 4 x\ The ESO's status is set to 
C Z4' and processing of the ESO is suspended until the Restart ESOs in Z4 Status 
(ZMOMI03) module (319) are triggered. 

After Pre-ATP is performed, the interface table ZATPDEM is polled every 
3 seconds to see if the results from ATP have been posted. If all delivery schedules 
on the ESO have a response, then Post- ATP (Z_IDOC__INPUT_POST_ATP) is 
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performed. The loop is repeated until all delivery schedules have a response or 
time limit exceeded (up to 20 times or 1 minute elapsed time). If the time limit is 
exceeded, then the Pre- ATP function is re-executed with TRIGGERZMOMI03 
set to c x\ When the Restart ESO in Z4 Status ZMOM103 module 319 is 
triggered, then Post- ATP is performed to pick back up the processing of the ESO. 




Please substitute the following paragraph for the paragraph on page 65 starting at 

line 19: 

There is some initial configuration to be done prior to using the workbench. 
Q This configuration is not covered in this document, such as: to configure a specific 

j ^1 customer to always manually review its orders. The CSR has the capability to 
branch to selected configuration processes from the workbench. This will be 
covered in detail later in this document. The order interceptor documentation, 
above, explains the customer-specific rules and configuration. 



Please substitute the following paragraph for the paragraph on page 67 starting at 

line 19: 

^ If PROFIT Commit data is present, the CSR can not change any data because the 

I ^ dates and quantities are already committed for that plant. 
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Please substitute the following table for the table on page 69: 



a, 



1 



Delivery Schedules 



Materials on EDI Trx 



Allows the CSR to view/change the 
dates and quantities at the delivery 
schedule level. There could be 
multiple delivery schedules per item. 
Other key data is also displayed at 
this level such as the MOQ and SPQ 
quantities for that material. You may 
use the checkbox to view that 
specific item's delivery schedules or 
simply hit the Delivery Schedules 
pushbutton to page through each 
one. 



A popup window displays all the 
material number(s) that existed on 
the inbound EDI transaction. It also 
shows what kind of material number 
it is in terms of customer's material 
number, Vendor's material number, 
changeable/catalog material number, 
etc. 



Please substitute the following paragraph for the paragraph on page 72 starting at 
line 19: 



This screen, as shown in Figure 7, allows the CSR to review/change all the 
^ delivery schedules for a line item. Both the date and quantity are modifiable fields. 

t^g) If there are multiple delivery schedules, these will be scrollable via the page up and 
page down. Please note that if you change one or more of the delivery schedules, 
the workbench will automatically accumulate the total to be updated on the item 



